…ty sequence

MS.DI guarantees that `IEnumerable<T>` resolves for every `T`, empty when nothing is registered, so consumers enumerate one without a null check and frameworks use a collection as their extension point. The provider-replacement path answered null instead, because the generator emits collection cases only for element types the graph mentions.

The objection recorded against this gap was that matching MS.DI means building a collection for a type unknown at compile time. That holds for a non-empty collection; an empty one constructs no elements, only an array of the element type the caller already handed over, so it needs no compile-time expansion.

An element type the container does have a registration for is excluded, so a collection with an async-tainted member still throws the container's guidance rather than quietly reporting nothing. Only `IEnumerable<T>` is covered, matching MS.DI, which answers null for `T[]`, `IList<T>` and `IReadOnlyList<T>` of an unregistered element type as well. The keyed surface is untouched: MS.DI has no equivalent guarantee there.

A value-typed element stays unreported, which is the one remaining divergence and an AOT constraint rather than a semantic one: manifesting the array needs the `T[]` type, which native AOT generates on demand for every reference element kind but not for a value one, where `Array.CreateInstance` throws `NotSupportedException`.